Skip to main content

Team Charter

Vision​

Each Veteran is securely connected to the VA services that matter most to them regardless of device or VA org chart.

Mission statement​

A native mobile app that is a trusted source for Veterans to quickly and easily check the status of their VA services and complete simple, transactional tasks across their health and benefits.

What we work on​

Product suite​

  • Health, benefits, payments, and profile products and services.
  • Global systems like UI library, FE components, accessibility, devops, governance and documentation.

Product portfolio​

Health​

  • Appointments
  • Secure Messages
  • Prescriptions
  • Vaccines

Benefits​

  • Claims & appeals status
  • Disability rating
  • Letters

Profile​

  • Personal & military information

Payments​

  • Compensation

Team organization​

The VA mobile App team is split into two groups covering different areas of focus.

Red team​

Health-related products in the app.

Blue team​

Benefits-related products, global app features like navigation and single sign on (SIS), and incremental improvements and maintenance (aka TLC).

See teaming information for the team roster.

How we work​

Communications​

Slack DSVA “#va-mobile-app”:​

This is our main means of communication with each other. Keep as much conversation in public channels as possible, to minimize duplicative and extraneous communication.

GitHub​

  • Product and research documentation are on VA.gov repository.
  • Codebase and issues are on separate VA mobile repository.
  • Update tickets regularly. If conversations happen in Slack that are pertinent to a product or initiative, copy the useful info into GitHub/ZenHub.

See Team Norms for more details on team communications.

Team meeting cadence​

Stand-up​

Check in on people and product progress. Raise blockers.

  • Every Tuesday and Thursdays
  • 15-30 minutes
  • Red team at 1:30pm ET
  • Blue team at 2pm ET

Sprint Planning​

Outline work to be done this sprint in order to accomplish the team's goals.

  • Last Tuesday of every sprint
  • 1 hour
  • Red team at 1pm ET
  • Blue team at 2pm ET

Demo​

Showcase of work done during the previous sprint.

  • Thursday after the end of every sprint
  • 45 minutes
  • Entire team (Red + Blue) at 2:35 ET

Retro​

Open discussion on what has gone well, what has been challenging, and discussion of action items.

  • Mid-Thursday of every sprint
  • 45 minutes
  • Entire team (Red + Blue) at 2:30 ET

Sprint 0​

Team and POs working ahead of the team to define future initiatives. Create draft product briefs that we can pull from in the future. Open to anyone on the team.

  • 1 hour
  • Weekly on Wednesdays at 1:05pm ET

Scrum of Scrums (SoS)​

Product, leads, and PO get together to discuss:

  • Highlight the quarterly plan and review progress
  • Review changes in risks, dependencies, assumptions, or priority for the current sprint
  • Review insights from ongoing discovery or delivery work in the current sprint
  • Discuss the plan for the upcoming sprint
  • Rebalance team staffing if necessary
  • Triage unplanned work

Cadence:

  • 1 hour
  • Weekly on Tuesdays at 4:05pm ET

Quarterly Planning​

Outline work to be done next quarter in order to accomplish the team's goals.

  • Upcoming tentative dates
    • Q2 2023 - 4/4/23
    • Q3 2023 - 6/27/23
    • Q4 2023 - 10/3/23
    • Q1 2024 - 1/9/24
  • 2 hours
  • Entire team (Red + Blue)

GitHub Etiquette​

  • Anyone on the team can create a(n) issue/ticket/story.
  • All teammates are responsible for keeping them up to date.
  • Templates are available within the new issue/ticket/story during creation.

Labels to use:​

  • Team assigned (mobile-blue-team, etc)
  • Discipline(s) (ux, content, front-end, back-end, qa)
  • Feature area(s) if applicable (direct-deposit, payments, etc.)
  • For bugs, add the bug tag and applicable severity tag

Epics should include:​

  • Clear acceptance criteria
  • Definition of done
  • A user story that reflects the benefit to a Veteran, Caregiver, or other user
  • Been broken up into discrete tasks/Github tickets that are attached to the epic
  • All components/steps have been accounted for in the epic
  • Documented risks: Risks: Value Risk, Feasibility Risk, Business Viability Risk, Usability Risk

Stories/Tickets should include:​

  • Title that explains the goal in plain language
  • Linked to another ticket or epic
  • Includes:
    • Description (what happened & why we need this ticket),
    • General tasks to perform
    • Acceptance criteria (expected result)

Estimation​

We use fibonacci numbers (1, 2, 3, 5, 8, 13) to account for the level of effort, complexity, and amount of unknowns in our work. Here is our guide:

PointsComplexityMeaning
1xxsmallTrivial change - Up to 2 hours (time mostly in submitting the work)
2xsmallSmall change - Up to 4 hours (More validation is required)
3smallRoutine addon/none new - 1 to 2 days (small work/high domain knowledge/1 or no moving parts)
5mediumRoutine addon/none new - 2 to 3 days (medium work/1-2 moving parts)
8largeNew work/High Complexity - 3 to 5 days (over 2 moving parts)
13xlargeToo big/Risky, should be broken down - 1 to 2 weeks